Introduce separate thread pool for establishing Initiator connections #255
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
* Fixes #254 * introduced separate thread pool with 3 threads for connection establishment * changed `enabled` flag in `Session` to `volatile` and removed synchronization from `setEnabled`/`isEnabled` since I could not find any good reason why it was synchronized ** `volatile` should ensure that all threads should see the current state and prevents possible deadlocks now that flag is checked from distinct threads * removed `synchronized` from `IoSessionInitiator.ConnectTask.run()` since I could not find any good reason why it was synchronized
to test LGTM check
philipwhiuk
approved these changes
Feb 6, 2020
…j/quickfixj into connection-timeout-254
AbstractSessionConnectorBuilder
- by default 3 threads are used - changed executor to be non-static, i.e. each Initiator instance has its own reconnect thread pool - (unless feature is disabled which will use the former behaviour) - to use the former behaviour (i.e. use "QFJ Timer" thread for both reconnections and calls to next()) you should pass 0 as number of reconnect threads - when passing 1 you will end up with a separate thread for reconnections; next() will still be called by "QFJ Timer" thread
chrjohn
commented
Apr 27, 2020
| super(settings, sessionFactory); | ||
| IoBuffer.setAllocator(new SimpleBufferAllocator()); | ||
| IoBuffer.setUseDirectBuffer(false); | ||
| if (numReconnectThreads > 0) { | ||
| scheduledReconnectExecutor = Executors.newScheduledThreadPool(numReconnectThreads, new QFScheduledReconnectThreadFactory()); | ||
| ((ThreadPoolExecutor) scheduledReconnectExecutor).setMaximumPoolSize(numReconnectThreads); |
There was a problem hiding this comment.
Setting maximumPoolSize to initialPoolSize ensures that numReconnectThreads threads are available to service tasks. Otherwise new threads only get created when the task queue is full.
the-thing
reviewed
May 13, 2020
| @@ -318,7 +318,7 @@ protected void startSessionTimer() { | |||
| if (shortLivedExecutor != null) { | |||
| timerTask = new DelegatingTask(timerTask, shortLivedExecutor); | |||
| } | |||
| sessionTimerFuture = scheduledExecutorService.scheduleAtFixedRate(timerTask, 0, 1000L, | |||
| sessionTimerFuture = SCHEDULED_EXECUTOR.scheduleAtFixedRate(timerTask, 0, 1000L, | |||
There was a problem hiding this comment.
Not directly related to this change, but we probably don't want to queue up timer tasks if they take too long for some reason.
There was a problem hiding this comment.
The reconnectTasks timed out after a maximum of 2000ms. That was the reason to have a bigger pool to service these requests, see #254 .
What do you suggest to prevent piling up these tasks?
There was a problem hiding this comment.
Similar to IoSessionInitiator. As a rule of thumb scheduleWithFixedDelay is better in majority of cases than scheduleAtFixedRate. It respects the delay, but it only reschedules when the tasks finishes - this does not allow bursts if for some reason task is slow.
the-thing
approved these changes
May 13, 2020
jli8000
pushed a commit
to jli8000/quickfixj
that referenced
this pull request
Sep 22, 2020
…quickfix-j#255) * Fixes quickfix-j#254 * introduced separate thread pool with 3 threads for connection establishment * changed `enabled` flag in `Session` to `volatile` and removed synchronization from `setEnabled`/`isEnabled` since I could not find any good reason why it was synchronized ** `volatile` should ensure that all threads should see the current state and prevents possible deadlocks now that flag is checked from distinct threads * removed `synchronized` from `IoSessionInitiator.ConnectTask.run()` since I could not find any good reason why it was synchronized * - prevent NPE on Logon in Session when not specifying messageFactory in AbstractSessionConnectorBuilder * - added possibility to specify number of reconnect threads via builder - by default 3 threads are used - changed executor to be non-static, i.e. each Initiator instance has its own reconnect thread pool - (unless feature is disabled which will use the former behaviour) - to use the former behaviour (i.e. use "QFJ Timer" thread for both reconnections and calls to next()) you should pass 0 as number of reconnect threads - when passing 1 you will end up with a separate thread for reconnections; next() will still be called by "QFJ Timer" thread
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #254
enabledflag inSessiontovolatileand removed synchronization fromsetEnabled/isEnabledsince I could not find any good reason why it was synchronized**
volatileshould be enough to ensure that all threads see the current state now that it is checked from distinct threadssynchronizedfromIoSessionInitiator.ConnectTask.run()since I could not find any good reason why it was synchronized